Event Sourcing: Впровадження аудит-трейлів для надійних і відстежуваних систем

У сучасному складному та взаємопов'язаному цифровому ландшафті підтримка надійного та всебічного аудит-трейлу має першорядне значення. Це не тільки часто є регуляторною вимогою, але й має вирішальне значення для налагодження, аналізу безпеки та розуміння еволюції вашої системи. Event Sourcing, архітектурний шаблон, який фіксує всі зміни стану програми як послідовність подій, пропонує елегантне та потужне рішення для впровадження аудит-трейлів, які є надійними, підлягають аудиту та розширюваними.

Що таке Event Sourcing?

Традиційні програми зазвичай зберігають лише поточний стан даних у базі даних. Цей підхід ускладнює відновлення минулих станів або розуміння серії подій, що призвели до поточного стану. Event Sourcing, навпаки, зосереджується на фіксації кожної значної зміни стану програми як незмінної події. Ці події зберігаються у сховищі подій із лише додатковим записом, утворюючи повний і хронологічний запис усіх дій у системі.

Уявіть це як виписку з банківського рахунку. Замість простого запису поточного балансу, кожне поповнення, зняття та переказ записуються як окрема подія. Відтворивши ці події, ви можете відтворити стан рахунку в будь-який момент часу.

Чому використовувати Event Sourcing для аудит-трейлів?

Event Sourcing пропонує кілька переконливих переваг для впровадження аудит-трейлів:

• Повна та незмінна історія: Кожна зміна фіксується як подія, забезпечуючи повний і незмінний запис еволюції системи. Це гарантує, що аудит-трейл є точним і захищеним від несанкціонованого доступу.
• Темпоральні запити: Ви можете легко відтворити стан системи в будь-який момент часу, відтворивши події до цього моменту. Це забезпечує потужні можливості темпоральних запитів для аудиту та аналізу.
• Підлягає аудиту та відстежується: Кожна подія зазвичай містить метадані, такі як мітка часу, ідентифікатор користувача та ідентифікатор транзакції, що полегшує відстеження походження та впливу кожної зміни.
• Відокремлення та масштабованість: Event Sourcing сприяє відокремленню між різними частинами системи. Події можуть використовуватися кількома передплатниками, забезпечуючи масштабованість і гнучкість.
• Відтворення для налагодження та відновлення: Події можна відтворити, щоб відтворити минулі стани для налагодження або для відновлення після помилок.
• Підтримка CQRS: Event Sourcing часто використовується разом із шаблоном Command Query Responsibility Segregation (CQRS), який розділяє операції читання та запису, ще більше покращуючи продуктивність і масштабованість.

Впровадження Event Sourcing для аудит-трейлів: покрокова інструкція

Ось практичний посібник з впровадження Event Sourcing для аудит-трейлів:

1. Визначте ключові події

Першим кроком є визначення ключових подій, які ви хочете зафіксувати у своєму аудит-трейлі. Ці події мають представляти значні зміни в стані програми. Розгляньте такі дії:

• Автентифікація користувача (вхід, вихід)
• Створення, зміна та видалення даних
• Ініціювання та завершення транзакцій
• Зміни конфігурації
• Події, пов'язані з безпекою (наприклад, зміни контролю доступу)

Приклад: Для платформи електронної комерції ключові події можуть включати «OrderCreated», «PaymentReceived», «OrderShipped», «ProductAddedToCart» та «UserProfileUpdated».

2. Визначте структуру подій

Кожна подія має мати чітко визначену структуру, яка включає таку інформацію:

• Тип події: Унікальний ідентифікатор типу події (наприклад, «OrderCreated»).
• Дані події: Дані, пов'язані з подією, наприклад ідентифікатор замовлення, ідентифікатор продукту, ідентифікатор клієнта та сума платежу.
• Мітка часу: Дата та час, коли відбулася подія. Розгляньте можливість використання UTC для узгодженості в різних часових поясах.
• Ідентифікатор користувача: Ідентифікатор користувача, який ініціював подію.
• Ідентифікатор транзакції: Унікальний ідентифікатор транзакції, до якої належить подія. Це має вирішальне значення для забезпечення атомарності та узгодженості між кількома подіями.
• Ідентифікатор кореляції: Ідентифікатор, який використовується для відстеження пов'язаних подій у різних службах або компонентах. Це особливо корисно в архітектурах мікросервісів.
• Ідентифікатор причини: (Необов'язково) Ідентифікатор події, яка спричинила цю подію. Це допомагає відстежити причинний ланцюжок подій.
• Метадані: Додаткова контекстна інформація, наприклад IP-адреса користувача, тип браузера або географічне розташування. Будьте уважні до правил конфіденційності даних, таких як GDPR, під час збору та зберігання метаданих.

Приклад: Подія «OrderCreated» може мати таку структуру:

{
  "eventType": "OrderCreated",
  "eventData": {
    "orderId": "12345",
    "customerId": "67890",
    "orderDate": "2023-10-27T10:00:00Z",
    "totalAmount": 100.00,
    "currency": "USD",
    "shippingAddress": {
      "street": "123 Main St",
      "city": "Anytown",
      "state": "CA",
      "zipCode": "91234",
      "country": "USA"
    }
  },
  "timestamp": "2023-10-27T10:00:00Z",
  "userId": "user123",
  "transactionId": "tx12345",
  "correlationId": "corr123",
  "metadata": {
    "ipAddress": "192.168.1.1",
    "browser": "Chrome",
    "location": {
       "latitude": 34.0522,
       "longitude": -118.2437
    }
  }
}

3. Виберіть сховище подій

Сховище подій — це центральне сховище для зберігання подій. Це має бути база даних лише з додатковим записом, яка оптимізована для запису та читання послідовностей подій. Доступно кілька варіантів:

• Виділені бази даних сховища подій: Це бази даних, спеціально розроблені для Event Sourcing, такі як EventStoreDB та AxonDB. Вони пропонують такі функції, як потоки подій, проекції та підписки.
• Реляційні бази даних: Ви можете використовувати реляційну базу даних, таку як PostgreSQL або MySQL, як сховище подій. Однак вам потрібно буде самостійно реалізувати семантику лише з додатковим записом і керування потоком подій. Розгляньте можливість використання спеціальної таблиці для подій із стовпцями для ідентифікатора події, типу події, даних події, мітки часу та метаданих.
• Бази даних NoSQL: Бази даних NoSQL, такі як MongoDB або Cassandra, також можна використовувати як сховища подій. Вони пропонують гнучкість і масштабованість, але можуть вимагати більше зусиль для реалізації необхідних функцій.
• Хмарні рішення: Хмарні провайдери, такі як AWS, Azure та Google Cloud, пропонують керовані служби потокової передачі подій, такі як Kafka, Kinesis та Pub/Sub, які можна використовувати як сховища подій. Ці служби забезпечують масштабованість, надійність та інтеграцію з іншими хмарними сервісами.

Вибираючи сховище подій, враховуйте такі фактори:

• Масштабованість: Чи може сховище подій обробляти очікуваний обсяг подій?
• Надійність: Наскільки надійне сховище подій з точки зору запобігання втраті даних?
• Можливості запитів: Чи підтримує сховище подій типи запитів, які вам потрібні для аудиту та аналізу?
• Підтримка транзакцій: Чи підтримує сховище подій транзакції ACID для забезпечення цілісності даних?
• Інтеграція: Чи добре сховище подій інтегрується з вашою існуючою інфраструктурою та інструментами?
• Вартість: Яка вартість використання сховища подій, включаючи витрати на зберігання, обчислення та мережу?

4. Реалізуйте публікацію подій

Коли відбувається подія, ваша програма має опублікувати її у сховищі подій. Зазвичай це передбачає такі дії:

• Створіть об'єкт події: Створіть об'єкт події, який містить тип події, дані події, мітку часу, ідентифікатор користувача та інші відповідні метадані.
• Серіалізуйте подію: Серіалізуйте об'єкт події у формат, який можна зберігати у сховищі подій, наприклад JSON або Avro.
• Додайте подію до сховища подій: Додайте серіалізовану подію до сховища подій. Переконайтеся, що ця операція є атомарною, щоб запобігти пошкодженню даних.
• Опублікуйте подію передплатникам: (Необов'язково) Опублікуйте подію будь-яким передплатникам, які зацікавлені в її отриманні. Це можна зробити за допомогою черги повідомлень або шаблону публікації-підписки.

Приклад (використання гіпотетичного EventStoreService):

public class OrderService {

  private final EventStoreService eventStoreService;

  public OrderService(EventStoreService eventStoreService) {
    this.eventStoreService = eventStoreService;
  }

  public void createOrder(Order order, String userId) {
    // ... бізнес-логіка для створення замовлення ...

    OrderCreatedEvent event = new OrderCreatedEvent(
        order.getOrderId(),
        order.getCustomerId(),
        order.getOrderDate(),
        order.getTotalAmount(),
        order.getCurrency(),
        order.getShippingAddress()
    );

    eventStoreService.appendEvent("order", order.getOrderId(), event, userId);
  }
}

public class EventStoreService {

  public void appendEvent(String streamName, String entityId, Object event, String userId) {
    // Створити об'єкт події
    EventRecord eventRecord = new EventRecord(
        UUID.randomUUID(), // eventId
        streamName,  // streamName
        entityId,   // entityId
        event.getClass().getName(), // eventType
        toJson(event),  // eventData
        Instant.now().toString(), // timestamp
        userId  // userId
    );

    // Серіалізувати подію
    String serializedEvent = toJson(eventRecord);

    // Додати подію до сховища подій (реалізація залежить від обраного сховища подій)
    storeEventInDatabase(serializedEvent);

    // Опублікувати подію передплатникам (необов'язково)
    publishEventToMessageQueue(serializedEvent);
  }

  // Заповнювачі методів для взаємодії з базою даних та чергою повідомлень
  private void storeEventInDatabase(String serializedEvent) {
    // Реалізація для збереження події в базі даних
    System.out.println("Збереження події в базі даних: " + serializedEvent);
  }

  private void publishEventToMessageQueue(String serializedEvent) {
    // Реалізація для публікації події в черзі повідомлень
    System.out.println("Публікація події в черзі повідомлень: " + serializedEvent);
  }

  private String toJson(Object obj) {
    // Реалізація серіалізації події до JSON
    try {
      ObjectMapper mapper = new ObjectMapper();
      return mapper.writeValueAsString(obj);
    } catch (Exception e) {
      throw new RuntimeException("Помилка серіалізації події до JSON", e);
    }
  }
}


class EventRecord {
  private final UUID eventId;
  private final String streamName;
  private final String entityId;
  private final String eventType;
  private final String eventData;
  private final String timestamp;
  private final String userId;

  public EventRecord(UUID eventId, String streamName, String entityId, String eventType, String eventData, String timestamp, String userId) {
    this.eventId = eventId;
    this.streamName = streamName;
    this.entityId = entityId;
    this.eventType = eventType;
    this.eventData = eventData;
    this.timestamp = timestamp;
    this.userId = userId;
  }

  // Getters

  @Override
  public String toString() {
    return "EventRecord{" +
        "eventId=" + eventId +
        ", streamName='" + streamName + '\'' +
        ", entityId='" + entityId + '\'' +
        ", eventType='" + eventType + '\'' +
        ", eventData='" + eventData + '\'' +
        ", timestamp='" + timestamp + '\'' +
        ", userId='" + userId + '\'' +
        '}';
  }
}

class OrderCreatedEvent {
    private final String orderId;
    private final String customerId;
    private final String orderDate;
    private final double totalAmount;
    private final String currency;
    private final String shippingAddress;

    public OrderCreatedEvent(String orderId, String customerId, String orderDate, double totalAmount, String currency, String shippingAddress) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
        this.shippingAddress = shippingAddress;
    }

    // Getters for all fields

    public String getOrderId() { return orderId; }
    public String getCustomerId() { return customerId; }
    public String getOrderDate() { return orderDate; }
    public double getTotalAmount() { return totalAmount; }
    public String getCurrency() { return currency; }
    public String getShippingAddress() { return shippingAddress; }

    @Override
    public String toString() {
        return "OrderCreatedEvent{"
                + "orderId='" + orderId + '\''
                + ", customerId='" + customerId + '\''
                + ", orderDate='" + orderDate + '\''
                + ", totalAmount=" + totalAmount
                + ", currency='" + currency + '\''
                + ", shippingAddress='" + shippingAddress + '\''
                + '}';
    }
}

class Order {
  private final String orderId;
  private final String customerId;
  private final String orderDate;
  private final double totalAmount;
  private final String currency;
  private final String shippingAddress;

  public Order(String orderId, String customerId, String orderDate, double totalAmount, String currency, String shippingAddress) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
        this.shippingAddress = shippingAddress;
    }

    // Getters for all fields

    public String getOrderId() { return orderId; }
    public String getCustomerId() { return customerId; }
    public String getOrderDate() { return orderDate; }
    public double getTotalAmount() { return totalAmount; }
    public String getCurrency() { return currency; }
    public String getShippingAddress() { return shippingAddress; }

    @Override
    public String toString() {
        return "Order{" +
                "orderId='" + orderId + '\''
                + ", customerId='" + customerId + '\''
                + ", orderDate='" + orderDate + '\''
                + ", totalAmount=" + totalAmount
                + ", currency='" + currency + '\''
                + ", shippingAddress='" + shippingAddress + '\''
                + '}';
    }
}

5. Створення моделей читання (проекції)

Хоча сховище подій надає повну історію всіх змін, часто неефективно запитувати його безпосередньо для операцій читання. Замість цього ви можете створити моделі читання, також відомі як проекції, які оптимізовані для певних шаблонів запитів. Ці моделі читання отримуються з потоку подій і асинхронно оновлюються під час публікації нових подій.

Приклад: Ви можете створити модель читання, яка містить список усіх замовлень для певного клієнта, або модель читання, яка узагальнює дані про продажі для певного продукту.

Щоб створити модель читання, ви підписуєтесь на потік подій і обробляєте кожну подію. Для кожної події ви відповідно оновлюєте модель читання.

Приклад:

public class OrderSummaryReadModelUpdater {

    private final OrderSummaryRepository orderSummaryRepository;

    public OrderSummaryReadModelUpdater(OrderSummaryRepository orderSummaryRepository) {
        this.orderSummaryRepository = orderSummaryRepository;
    }

    public void handle(OrderCreatedEvent event) {
        OrderSummary orderSummary = new OrderSummary(
                event.getOrderId(),
                event.getCustomerId(),
                event.getOrderDate(),
                event.getTotalAmount(),
                event.getCurrency()
        );

        orderSummaryRepository.save(orderSummary);
    }

    // Інші обробники подій для PaymentReceivedEvent, OrderShippedEvent тощо.
}

interface OrderSummaryRepository {
    void save(OrderSummary orderSummary);
}

class OrderSummary {
    private final String orderId;
    private final String customerId;
    private final String orderDate;
    private final double totalAmount;
    private final String currency;

    public OrderSummary(String orderId, String customerId, String orderDate, double totalAmount, String currency) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
    }
    //Getters
}

6. Захистіть сховище подій

Сховище подій містить конфіденційні дані, тому важливо правильно його захистити. Розгляньте такі заходи безпеки:

• Контроль доступу: Обмежте доступ до сховища подій лише авторизованими користувачами та програмами. Використовуйте надійні механізми автентифікації та авторизації.
• Шифрування: Зашифруйте дані в сховищі подій у стані спокою та під час передачі, щоб захистити їх від несанкціонованого доступу. Розгляньте можливість використання ключів шифрування, керованих модулем безпеки обладнання (HSM), для додаткової безпеки.
• Аудит: Аудит всього доступу до сховища подій для виявлення та запобігання несанкціонованій діяльності.
• Маскування даних: Замаскуйте конфіденційні дані в сховищі подій, щоб захистити їх від несанкціонованого розкриття. Наприклад, ви можете замаскувати особисту інформацію (PII), таку як номери кредитних карток або номери соціального страхування.
• Регулярне резервне копіювання: Регулярно створюйте резервні копії сховища подій, щоб захиститися від втрати даних. Зберігайте резервні копії в безпечному місці.
• Відновлення після аварій: Впровадьте план відновлення після аварій, щоб забезпечити можливість відновлення сховища подій у разі аварії.

7. Реалізуйте аудит і звітність

Після того, як ви реалізували Event Sourcing, ви можете використовувати потік подій для створення аудит-звітів і виконання аналізу безпеки. Ви можете запитувати сховище подій, щоб знайти всі події, пов'язані з певним користувачем, транзакцією або сутністю. Ви також можете використовувати потік подій для відновлення стану системи в будь-який момент часу.

Приклад: Ви можете створити звіт, який показує всі зміни, внесені до певного профілю користувача за певний період часу, або звіт, який показує всі транзакції, ініційовані певним користувачем.

Розгляньте такі можливості звітності:

• Звіти про активність користувача: Відстежуйте вхід користувачів, вихід і інші дії.
• Звіти про зміну даних: Відстежуйте зміни до критичних сутностей даних.
• Звіти про події безпеки: Сповіщення про підозрілу діяльність, наприклад невдалі спроби входу або спроби несанкціонованого доступу.
• Звіти про відповідність: Створення звітів, необхідних для відповідності нормативним вимогам (наприклад, GDPR, HIPAA).

Виклики Event Sourcing

Хоча Event Sourcing пропонує багато переваг, він також представляє певні виклики:

• Складність: Event Sourcing додає складності архітектурі системи. Вам потрібно розробити структуру подій, вибрати сховище подій та реалізувати публікацію та споживання подій.
• Остаточна узгодженість: Моделі читання остаточно узгоджуються з потоком подій. Це означає, що може бути затримка між виникненням події та оновленням моделі читання. Це може призвести до неузгодженостей в інтерфейсі користувача.
• Версіонування подій: У міру розвитку вашої програми вам може знадобитися змінити структуру ваших подій. Це може бути складно, оскільки вам потрібно переконатися, що наявні події все ще можуть бути оброблені правильно. Розгляньте можливість використання таких методів, як підвищення версії подій, щоб обробляти різні версії подій.
• Остаточна узгодженість і розподілені транзакції: Реалізація розподілених транзакцій з Event Sourcing може бути складною. Вам потрібно переконатися, що події публікуються та використовуються узгодженим чином у кількох службах.
• Операційні витрати: Управління сховищем подій і пов'язаною з ним інфраструктурою може додати операційні витрати. Вам потрібно контролювати сховище подій, створювати його резервні копії та переконатися, що воно працює безперебійно.

Найкращі практики Event Sourcing

Щоб пом'якшити проблеми Event Sourcing, дотримуйтесь цих найкращих практик:

• Почніть з малого: Почніть з реалізації Event Sourcing у невеликій частині вашої програми. Це дозволить вам вивчити концепції та отримати досвід, перш ніж застосовувати їх до більш складних областей.
• Використовуйте фреймворк: Використовуйте фреймворк, як-от Axon Framework або Spring Cloud Stream, щоб спростити реалізацію Event Sourcing. Ці фреймворки надають абстракції та інструменти, які можуть допомогти вам керувати подіями, проекціями та підписками.
• Ретельно розробляйте події: Ретельно розробляйте свої події, щоб переконатися, що вони містять всю необхідну інформацію. Не включайте занадто багато інформації в події, оскільки це може ускладнити їх обробку.
• Реалізуйте підвищення версії подій: Реалізуйте підвищення версії подій, щоб обробляти зміни у структурі ваших подій. Це дозволить вам обробляти наявні події навіть після зміни структури подій.
• Контролюйте систему: Уважно контролюйте систему, щоб виявляти та запобігати помилкам. Контролюйте сховище подій, процес публікації подій та оновлення моделей читання.
• Обробляйте ідемпотентність: Переконайтеся, що ваші обробники подій є ідемпотентними. Це означає, що вони можуть обробляти одну й ту саму подію кілька разів, не завдаючи ніякої шкоди. Це важливо, оскільки події можуть бути доставлені більше одного разу в розподіленій системі.
• Розгляньте компенсуючі транзакції: Якщо операція завершилася невдало після публікації події, вам може знадобитися виконати компенсуючу транзакцію, щоб скасувати зміни. Наприклад, якщо замовлення створено, але оплата не вдалася, вам може знадобитися скасувати замовлення.

Приклади Event Sourcing у реальному світі

Event Sourcing використовується в різних галузях і додатках, зокрема:

• Фінансові послуги: Банки та фінансові установи використовують Event Sourcing для відстеження транзакцій, управління рахунками та виявлення шахрайства.
• Електронна комерція: Компанії електронної комерції використовують Event Sourcing для керування замовленнями, відстеження запасів та персоналізації взаємодії з клієнтами.
• Ігри: Розробники ігор використовують Event Sourcing для відстеження стану гри, керування прогресом гравців та реалізації багатокористувацьких функцій.
• Управління ланцюгом поставок: Компанії ланцюга поставок використовують Event Sourcing для відстеження товарів, управління запасами та оптимізації логістики.
• Охорона здоров'я: Постачальники медичних послуг використовують Event Sourcing для відстеження записів пацієнтів, керування зустрічами та покращення догляду за пацієнтами.
• Глобальна логістика: Такі компанії, як Maersk або DHL, можуть використовувати event sourcing для відстеження вантажів по всьому світу, фіксуючи такі події, як «ВантажВідправленийЗПорту», «ВантажПрибувВПорт», «МитнеОформленняРозпочато» та «ВантажДоставлено». Це створює повний аудит-трейл для кожного відправлення.
• Міжнародні банківські операції: Банки, такі як HSBC або Standard Chartered, можуть використовувати event sourcing для відстеження міжнародних грошових переказів, фіксуючи такі події, як «ПереказІніційовано», «ОбмінВалютВиконано», «КоштиНадісланоБанкуБенефіціара» та «КоштиОтриманоБенефіціаром». Це допомагає забезпечити відповідність нормативним вимогам і полегшує виявлення шахрайства.

Висновок

Event Sourcing – це потужний архітектурний шаблон, який може революціонізувати вашу реалізацію аудит-трейлу. Він забезпечує неперевершену трасування, цілісність даних і стійкість системи. Незважаючи на певні виклики, переваги Event Sourcing часто переважають витрати, особливо для складних і критичних систем. Дотримуючись найкращих практик, викладених у цьому посібнику, ви можете успішно впровадити Event Sourcing і створити надійні та підлягаючі аудиту системи.

Додаткове читання

• Event Sourcing від Мартіна Фаулера
• EventStoreDB
• Axon Framework